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(54) Real time transmission of musical tone Information 

(57) A musical tone data communications system 
having a unit for generating MIDI data of a musical per- 
formance by a player, a unit for transmitting the gener- 
ated MIDI data over a communications network and a 
unit for receiving the transmitted MIDI data and repro- 
ducing musical tones corresponding to the MIDI data in 
real time. 
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Description 

This application is based on Japanese Patent Applications No. 8-349939 filed on December 27, 1996 and No. 9- 
059600 filed on March 13, 1997, the entire contents of which are incorporated herein by reference. 

5 

BACKGROUND OF THE INVENTION 
a) Field of the Invention 

10 The present invention relates to data communications technologies, and more particularly to real time data com- 
munications technologies. A "real time" response to an event is essentially simultaneous with the event itself. However, 
in communications, because of time delay for transmission time, 6ignal synchronization, other necessary 6ignal process 
or the like, "real time" does not mean strictly simultaneous. 

is b) Description of the Related Art 

As a standard specification for communications between electronic musical instruments, a music instrumental dig- 
ital interface (MIDI) specification is known. Electronic musical instruments equipped with interfaces of the MIDI specifi- 
cation can communicate with each other by transferring MIDI data via a MIDI cable. 

20 For example, an electronic musical instrument transmits MIDI data of a musical performance by a player, and 
another musical instrument receives it to reproduce it. As one electronic musical instrument is played, another elec- 
tronic musical instrument can be played in real time. 

In a communications network interconnecting a plurality of general computers, various types of data are trans- 
ferred. For example, live musical tone data or other MIDI data can be transmitted from one computer, which once stored 

25 the data in its storage device such as a hard disk, via the communications network to another computer which stores 
the received data in its storage device. A general communications network is. however, configured to perform only gen- 
eral data communications, and is not configured to properly process MIDI data. 

Specifically, although the MIDI specification allows the "real time" communications to be performed between elec- 
tronic musical instruments, it is not suitable for long distance communications and communications via a number of 

30 nodes. The general communications network is essentially configured to provide services of long distance communica- 
tions and multiple-node communications, but it does not take aocount of "real time" communications between electronic 
musical instruments. 

Real time communications of musical information uses a large amount of information per unit time, and the traffic 
of the communications line becomes heavy. As compared to point-to-point communications, point-to-muftipoint commu- 
35 nications of musical tone data is more likely to make the traffic of communications lines heavy. The heavy traffic of com- 
munications lines generates a transmission delay and hinders a real time musical performance. 

SUMMARY OF THE INVENTION 

40 It is an object of the present invention to provide technologies of musical tone data communications capable of a 
real time musical performance at multiple nodes. 

It is another object of the present invention to provide technologies of data communications capable of avoiding a 
heavy traffic of communications lines. 

According to one aspect of the present invention, there is provided a musical tone data communications system, 
45 comprising: transmitting means for transmitting inputted MIDI data in real time over a communication network. 

According to another aspect of the present invention, there is provided a data communications system comprising: 
receiving means for receiving data; access checking means for checking the number of communications lines accessed 
externally; and transmitting means capable of reducing the amount of data received by the receiving means in accord- 
ance with the number of communications lines accessed externally, and transmitting the reduced data to the communi- 
so cations lines accessed externally. 

If the number of accessed communications lines is large, the amount of received data is reduced to thereby allevi- 
ate the traffic congestion, whereas if the number of accessed communications lines is small, it is not always necessary 
to reduce the data amount 

According to a further aspect of the present invention, there is provided a communication system having a plurality 
55 of communications apparatuses each having receiving means and transmitting means, wherein: the receiving means 
of the plurality of communications apparatuses receive the same data; the transmitting means of the plurality of com- 
munications apparatuses can reduce the amount of data received by the receiving means and can transmit the reduced 
data; and the data reduced by one of the communications apparatuses is different from the data reduced by another of 
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the communications apparatuses. 

Since the data reduced by one and another of communications apparatuses is different, the quality of data trans- 
mitted from each communication apparatus is different. For example, the type or reduction factor of the reduced data 
may be made different at each communication apparatus. Therefore, a user can obtain data of a desired quality by 
s accessing a proper communication apparatus. 

According to still another aspect of the invention, there is provided a musical tone data communications method 
comprising the steps of: (a) transmitting MIDI data over a communications network; and (b) receiving the transmitted 
MIDI data and supplying the received MID! data to a tone generator in real time. 

MIDI data can be transmitted to a number of nodes by using a communications network. At each node, the MIDI 
10 data is reproduced in real time to generate musical tones. 

According to still another aspect of the invention, there is provided a musical tone data communications method 
comprising the steps of: (a) transmitting MIDI data; and (b) transmitting recovery data after the MIDI data is transmitted, 
the recovery data indicating a continuation of transmission of the MIDI data. | 

If there is no communications error, transmitted MIDI data can be correctly received at a partner communications 
15 apparatus. If there is a communications error, transmitted MIDI data cannot be correctly received at a partner commu- 
nications apparatus. Even in such a case, the communication error can be remedied by transmitting the recovery data. 

BRIEF DESCRIPTION OF THE DRAWINGS 

20 Fig. 1 is a schematic diagram showing a musical tone data communications network. 

Fig. 2 is a block diagram showing the hardware structure of an encoder and a home computer. 
Fig. 3 is a timing chart illustrating a method of dealing with MIDI data communications errors. 
Fig. 4 shows the format of a communications packet. 

Fig. 5 is a flow chart illustrating the operation of a transmission process to be performed by an encoder. 
25 Figs. 6A and 6B are flow charts illustrating the operation of an interrupt process to be performed by the encoder, 
the flow chart of Fig. 6A illustrating a transmission process of recovery key data and the flow chart of Fig. 6B illustrating 
a transmission process of recovery tone generator setting data. 

Fig. 7 is a flow chart illustrating the operation of a reception process to be performed by a home computer. 

Fig. 8 is a flow chart illustrating the details of an event process at Step SD6 of Fig. 7. 
30 Fig. 9 is a flow chart illustrating the operation of an interrupt process to be performed by a home computer. 

Fig. 10 is a diagram showing the structure of a memory of a proxity server. 

Fig. 1 1 is a graph showing the relationship between the number of accesses and a thinning index. 

Fig. 12 is a flow chart illustrating the operation of a process to be performed by a proxity server when a user 
accesses the proxity server. 

35 Fig. 13 is a flow chart illustrating the operation of a process to be performed by a proxity server when a user 
releases an access to the proxity server. 

Fig. 14 is a flow chart illustrating the operation of a process to be performed by a proxity server when it receives 
data from a main server. 

Fig. 15 is a flow chart illustrating the operation of a process to be performed by a proxity server when it thins recov- 
40 erydata. 

Fig. 1 6 is a flow chart illustrating the operation of a process to be performed by a proxity server when it preferentially 
transmits key-off event data. 

Fig. 17 is a flow chart illustrating the operation of a process to be performed by a proxity server when it transfers 
data by deleting image data. 

45 Fig. 18 is a flow chart illustrating the operation of a process to be performed by a proxity server when it transfers 
data by lowering a resolution of the data. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

so Fig. 1 shows a musical tone data communications network. 

A concert hall 1 is installed with a MIDI musical instrument 2, a camera 4, encoders 3 and 5, and a rooter 6. A player 
plays the M IDI musical instrument 2 in the concert hall 1 . The MIDI musical instrument 2 is an electronic musical instru- 
ment having a MIDI interface, generates MIDI data in real time in accordance with the performance by a player, and 
supplies it to the encoder 3. The encoder 3 transmits each packet of MIDI data of a predetermined format in real time 
55 to the Internet via the rooter 6. The data format will be later described with reference to Fig. 4. 

The camera 4 takes an image of a player and supplies it as image data to the encoder 5. The encoder 5 transmits 
each packet of image data of a predetermined format to the Internet via the rooter 6. A microphone 1 3 samples sounds 
of a vocal (voice data), an acoustic musical instrument (for example a piano), or an electric musical instrument, and sup- 
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plies these sample data to an encoder 14 as sound data. The encoder 14 transmits each packet of sound data of a pre- 
determined format to the Internet via the rooter 6. The data format will be later described with reference to Fig. 4. 

The rooter 6 transmits MIDI data and image data to the Internet to be described hereinunder. The data is supplied 
from the rooter 6 to a main server 7 via a public telephone line or a leased telephone line, and to a plurality of proxity 
5 servers 1 2a, 1 2bj, 1 2c,... and farther to a world wide web (WWW) server 8 which is called a provider. 

The proxity servers 12a, 12b, 12c ( ... are hereinafter called a proxity server 12 singularly or collectively. The proxity 
server 12 functions to avoid the traffic congestion of communications lines. The proxity server 12 controls the amount 
of data supplied from the main server 7 in accordance with the traffic conditions of communications lines and supplies 
the reduced data to the WWW server 8. For example, if the number of users (lines) is large, it is judged that the com- 
10 munications lines are congested, and the data is thinned to reduce the data amount and avoid the traffic congestion. 

A plurality of proxity servers 1 2a, 1 2b, 1 2c may have different data reduction amounts or different data reducing 

methods. The data reduction amount influences the sound and image qualities. The larger the data reduction amount, 
the lower the sound and image qualities. 

Fog example, the proxity server 12a may limit the number of accessible users to improve the sound and image 
is qualities, whereas another proxity server 12c may lower the sound and image qualities to increase the number of 
accessible users. Such a function of the proxity server 12 can alleviate the traffic congestion of communications lines. 

A user can access the Internet by connecting its home computer 9 to the WWW server 8 to receive MIDI data and 
image data in real time. The term "home computer" used herein is intended to mean any computer used for "home" con- 
cert as opposed to a remote concert hall. The home computer 9 has a display device for the display of image data and 
20 an external or built-in MIDI tone generator (sound source) for the generation of musical tone signals. The MIDI tone 
generator generates musical tone signals in accordance with MIDI data, and supplies the tone signals to a sound output 
device 1 1 . The sound output device 1 1 has a D/A converter, an amplifier and a speaker to reproduce sounds in accord- 
ance with the supplied tone signals. Sound data is reproduced, converted from an analog form to an digital form, ampli- 
fied by an amplifier, and reproduced as sounds from a speaker. Sounds same as those produced in the concert hall 1 
25 can be reproduced from the sound output device 1 1 in real time. — 

If an external MIDI tone generator 10 is used, the home computer 9 makes the MIDI generator 10 generate musical 
tone signals and the sound output device 1 1 reproduce sounds. 

Since the MIDI data and sound data are more important for a user than image data, the MIDI data and sound data 
are processed with a priority over the image data. Although a user does not feel uneasy about the image data with poor 
30 image quality and smaller frame number, sound information and musical tone information of MIDI data is required to 
have a high quality. 

Any user can listen to a musical performance in real time by connecting the home computer 9 to the Internet while 
looking at each scene of the concert hall 1 on the display device at home without going to the concert hall 1 . A number 
of users can enjoy at home the musical performance played in the remote concert hall. MIDI data is transmitted from 

35 the concert hall 1 to each user so that each user can share a situation of the concert hall 1 as if the player is playing the 
electronic musical instrument at user home. 

The promoter of a concert determines a prescribed number of the concert and sells tickets to users. Tickets may 
have ranks such as rank A (special seat), rank B (ordinary seat) and rank C (gallery). For example, a user with a rank 
A ticket can access the proxity server 12a for the reception of high quality sound and image information, a user with a 

40 rank B ticket can access the proxity server 12b for the reception of sound and image information with a reduced data 
amount, and a user with a rank C ticket can access the proxity server 12c for the reception of only sound information 
with a reduced data amount. 

Since not live musical tone information but MIDI data is transmitted over the Internet, the sound quality is not 
degraded by noises. However, since long distance communications via a number of communications sites is performed 
45 over the Internet, the following method of dealing with communications errors becomes necessary when data is trans- 
mitted from the encoders 3 and 5 and when the data is received at the home computer 9. For example, communications 
errors include data change, data loss, data duplication, data sequence change and the like. 

Fig. 2 shows the hardware structure of the encoders 3 and 5 and the home computer 9 which may be a general 
computer. 

so Connected to a bus 31 are an input device 26 such as a keyboard and a mouse, a display device 27, a MIDI tone 
generator 28, a communications interface 29 for connection to the Internet, a MIDI interface 30, a RAM 2 1 , a ROM 22, 
a CPU 23, and an external storage device 25. 

Various instructions can be entered from the input device 26. In the home computer 9, the display device 27 dis- 
plays each scene of a concert hall, and the MIDI tone generator 28 generates musical tone signals in accordance with 
55 received MIDI data and transmits them to an external circuitry. 

The communications interface 29 is used for transferring MIDI data and image data to and from the Internet. The 
MIDI interface 30 is used for transferring MIDI data to and from an external circuitry. 

The external storage device 25 may be a hard disk drive, a floppy disk drive, a CD-ROM drive, a magneto-optical 
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disk drive or the tike and may store therein MIDI data, image data, computer programs and the like. 

ROM 22 may store therein computer programs, various parameters and the like. RAM 21 has a key-on buffer 21a 
and a tone generator setting buffer 21b. The key-on buffer 21a stores a key-on event contained in MIDI data, and the 
tone generator setting buffer 21b stores tone generator setting data contained in MIDI data. 

5 RAM 21 has also working areas such as buffers and registers to copy and store data in ROM 22 and the external 

storage device 25. In accordance with computer programs stored in ROM 22 or RAM 21 , CPU 23 performs various cal- 
culations and signal processing. CPU 23 can fetch timing information from a timer 24. 

The external storage device 25 may be a hard disk drive (HDD). HDD 25 may store therein various data such as 
application program data and MIDI data. If a necessary application program is stored not in ROM 22 but in a hard disk 

io loaded in HDD 25, this program is read into RAM 21 so that CPU 23 can run this application program in the similar man- 
ner as if the program is stored in ROM 22. In this case, addition, version-up and the like of an application program 
become easy. The external storage device 25 includes HDD and a CD-ROM (compact-disk - read-only-memory) drive 
which can read various data such as application programs stored in a CD-ROM. The read data such as an application 
program is stored in a hard disk loaded in HDD. Installation, version-up and the like of an application program become 

is easy. Other types of drives such as a floppy disk drive, a magneto-optical (MO) disk drive may be used as the external 
storage device 25. 

The communications interface 29 is connected to a communications network 32 such as the Internet, a local area 
network (LAN) and a telephone line, and via the communications network 32 to a server computer 33. If application pro- 
grams and data are not stored in a hard disk loaded in HDD 25, these programs and data can be downloaded from the 

20 server computer 33. In this case, a client such as the encoder 3, 5 and home computer 9 transmits a command for 
downloading an application program or data to the server computer 33 via the communications interface 29 and com- 
munications network 32. Upon reception of this command, the server computer 33 supplies the requested application 
program or data to the client via the communications network 32 which client receives it via the communications inter- 
face 29 and stores it in a hard disk loaded in HDD 25. 

25 This embodiment may be reduced into practice by a commercially available personal computer installed with appli- 
cation programs and various data realizing the functions^ybjaembodiment. The application programs and various data 
may be supplied to a user in the form of a storage medium such as a CD-ROM and a floppy disk which the personal 
computer can read. If the personal computer is connected to the communications network such as the Internet, a LAN 
and a telephone line, the application programs and various data may be supplied to the personal computer via the com- 

30 munications network 

Fig. 3 is a diagram illustrating a method of dealing with communications errors of MIDI data, indicating a key-on 
event at a high level and a key-off event at a low level by way of example. 

in this example, a key-on event is transmitted at a timing t1 and a key-off event is transmitted at a timing t4. The 
key-on event transmitted at the timing t1 may be lost in some case by communications errors. In such a case, the home 
35 computer 9 on the reception side cannot receive the key-on event and receives only the key-off event so that a correct 
musical performance cannot be reproduced. The reception of only the key-off event without the key-on event will not 
occur according to the musical performance ode. 

In order to avoid such a case, during the period after the transmission of the key-on event at the timing t1 and before 
the transmission of the key-off event at the timing t4, recovery key data is transmitted periodically at a predetermined 
40 time interval, in this example, at timings t2 and t3. 

The recovery key-on data is confirmation data which notifies the reception side of a continuation of a key-on state. 
Even if the key-on event cannot be received at the timing t1 , the key-on event is enabled when the recovery key data is 
received at the timing t2 although there is some delay from the timing t1 . Similarly, even if the key-on event cannot be 
received both at the timings t1 and t2, it is enabled at the timing t3 when the recovery data is received. 
45 Generally, a musical tone signal attenuates with time, ft is therefore preferable to transmit the recovery key data with 
the information of a lowered velocity (sound volume) corresponding to the time lapse. The velocity information is always 
contained in the key-on event and transmitted together with the key-on event. In this example, key-on events (recovery 
key data) with gradually lowered velocities in the order of timings t1 , t2 and t3 are transmitted. 

A communications error of a key-on event can therefore be remedied by the recovery key data. A recovery method 
so to be used when the key-off event at the timing t4 is lost will be described next. 

It is possible to transmit key-off recovery data after the key-off event, similar to the recovery method for the key-on 
event. However, the time duration of a key-off is much longer than that of a key-on of each key of the keyboard. If the 
recovery key data is transmitted after the key-off event until the next key-on event occurs, the amount of this recovery 
key data becomes bulky. 

55 The recovery key data for the key-on event is transmitted during the period after the key-on timing t1 and before the 
key-off timing t4, and is not transmitted after the key-off timing t4. That the recovery key data is not transmitted means 
that a key-off event has already occurred. Therefore, if the home computer 9 cannot receive the key-off event at the tim- 
ing t4 but can detect that the recovery key data is not periodically transmitted, it is judged that the key state is presently 
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a key-off. 

If the recovery key data cannot be received periodically during the key-on, the home computer 9 can judge that 
there was a communications error, and enables the key-off so that a false continuation of sound reproduction can be 
avoided. This judgement is made by referring to the key-on buffer 21a shown in Fig. 2, and the details thereof will be 
s later described with reference to a flow chart. 

Similar to the key-on and key-off recovery, recovery tone generator setting data for recovering lost tone generator 
. setting data can be obtained by referring to the tone generator setting buffer 21b shown in Fig. 2. 

Fig. 4 shows the format of a communications packet. A communications packet is transmitted from the encoder 3, 
5 shown in Fig. 1 or received by the personal computer 9 shown in Fig. 1 . 
io The packet is constituted of a header field 41 and a data field 42. The header field 41 contains checksums 43 of 
two words (one word is 16 bits), a data ID 44 of four words, a sequence number 45 of four words, time data 46 of four 
words, and an event data length 47 of two words. 

The checksums 43 are representative values of all data in the header field 41 excepting the checksums and in the 
data field 42. The transmitting side calculates these representative values and transmits a packet added with the check- 
off sums 43. The receiving side recalculates the representative values of data in the packet and checks whether the recal- 
culated representative values are coincide with the transmitted checksums 43. If coincident, it is judged that there is no 
communications error. 

The data ID 44 is a number identifying the type of the data field 42. The numbers "0", "1 w and "2" indicate MIDI data 
and the number "3" indicates image data. The number "0" indicates real event data (ordinary MIDI data), the number 
20 T indicates the recovery key data (Fig. 3). and the number "2" indicates the recovery tone generator setting data. 

The sequence number 45 is a number assigned to each packet in the sequential order. By checking the sequence 
number 45, the receiving side can recover or reorder the packets even if the order of packets is changed by communi- 
cations errors. 

The time data 46 indicates a reproduction time representing 1 ms by one bit. Since this data 46 has four words, the 
25 time information of 100 hours or longer can be given. Using this time information 46 allows a simultaneous session of 
a plurality of concert halls. A simultaneous musical performance can be listened at home by assigning the time infor- 
mation 46 as a musical performance time at each concert hall and providing synchronization between a plurality of con- 
cert halls. Although the time information 46 is preferably an absolute time, it may be a relative time commonly used by 
all concert halls. 

30 The event data length 47 indicates the length of data in the data field 42. 

The data field 42 contains real data 48 which is MIDI data or image data. The MIDI data contains the recovery key 
data and recovery tone generator setting data. 

A high communications speed is preferable, for example, 64 K bits/s (ISDN). The data length of one packet is not 
limited. It is preferably about 1 K bytes or 512 bytes from the viewpoint of communications efficiency. 
35 Fig. 5 is a flow chart illustrating the operation of a transmission process to be executed by the encoder 3. 

At Step SA1 , MIDI data is received from the MIDI musical instrument 2. At Step SA2, the received data is buffered 
in RAM 21. 

At Step SA3, the type of an event of the received data is checked. The type of an event includes a key-on event, a 
key-off event and a tone generator setting data event. If the type is key-on, the flow advances to Step SA6 whereat the 
40 key-on event is registered in the key-on buffer 21a (Fig. 2) to thereafter follow Step SA7. 

If the type is key-off, the flow advances to Step SA4 whereat the key-on buffer 21 a is searched. If there is the same 
key code (sound pitch), the corresponding key-on event is deleted from the key-on buffer 21a to thereafter follow Step 
SA7. 

If the type is tone generator setting data, the flow advances to Step SA5 whereat the tone generator setting data is 
45 registered in the tone generator setting buffer 21 b (Fig. 2) to thereafter follow Step SA7. The tone generator setting data 
includes program change data, control data, exclusive message data, and the like. 

At Step SA7, the received MIDI data is added with, as shown in Fig. 4, checksums 43, a data ID (No. 0) 44 indicat- 
ing real event data, a sequence number 45, a time data 46 of the timer 24 (Fig. 2) and an event length 47. In this case, 
a plurality of events of the same type generated at generally the same time may be collected and configured into one 
so packet to be transmitted. After Step SA7, the transmission process is terminated. 

By using the same process, the encoder 4 transmits image data. In this case, the data ID 44 is No. 3. 
Figs. 6A and 6B are flow charts illustrating the interrupt process to be executed by the encoder 3. This interrupt 
process is performed at a predetermined interval in response to the timing supplied from the timer 24. For example, the 
interrupt process is performed at an interval of 100 to 200 \xs. 
55 Fig. 6A is a flow chart illustrating the transmission process of recovery key data. 

At Step SB1 , the key-on buffer 21 a (Fig. 2) is searched. At Step SB2, the key-on event data in the key-on buffer 21a 
is packeted as shown in Fig. 4 and transmitted as the recovery key data. In thi6 case, a velocity (sound volume) lower 
than that contained in the key-on event data stored in the key-on buffer 21 a is set to the recovery key data, the velocity 
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being set lower by an amount corresponding to the time lapse from the start of the key-on event. 

The data ID 44 in the packet is No. 1 indicating the recovery key data. The sequence number 45 of this packet is 
the same as that of the real event data (Fig. 5). After the recovery key data is transmitted, the process before this inter- 
rupt process is resumed. 

Fig. 6B is a flow chart illustrating the transmission process for recovery tone generator data. A relatively low preci- 
sion of time is required for this transmission process so that the process may be performed at an interval longer than 
that of the recovery key data transmission process (Fig. 6A). 

At Step SC1 . the tone generator setting buffer 21b (Fig. 2) is searched. At Steps SC2. the event data in the tone 
generator setting buffer 21 b is packeted as shown in Fig. 4 and transmitted as the recovery tone generator setting infor- 
mation. 

The data ID 44 in the packet is No. 2 indicating the recovery tone generator setting data. The sequence number 45 
of this packet is the same as those of the real event data (Fig. 5) and recovery key data (Fig. 6A). After the recovery 
tone generator setting data is transmitted, the process before this interrupt process is resumed. 

Fig. 7 is a flow chart illustrating the reception process to be executed by the home computer 9. 

At Step SD1, data on the Internet is received. At Step SD2, the checksums 43 (Fig. 4) in the received packet are 
checked. If not coincident, there is a data error or errors. 

At Step SD3 it is checked whether the check result of the checksums is normal or error. If error, it means that the 
data in the packet has an error or errors so that the flow advances to Step SD9 to terminate the process without per- 
forming any operation. Not performing any operation and discarding the data having less reliability is effective because 
false sound reproduction and setting are not performed. 

If the checksums are normal, the data in the packet is reliabte so that the flow advances to Step SD4 whereat the 
sequence number 45 (Fig. 4) in the packet is checked. In normal communications, the sequence number 45 increases 
each time a packet is received. However, the order of sequence numbers of received packets changes if there is a com- 
munications error or errors. 

It is checked at Step SD5 whether the received data has the correct sequence number 45 and the current time at 
the home computer 9 is the same as or later than the reproduction time 46 (Fig. 4). In the simultaneous session of a 
plurality of concert halls, there may be a concert hall whose time data 46 is still not the reproduction time. If the current 
time becomes the same as the time data 46, one of the above check conditions is satisfied. 

If the current time is before the reproduction time 46, the flow advances to Step SD10 whereat the received data is 
buffered in RAM for the preparation of a later process at the correct timing. After Step SD10, the reception process is 
terminated. 

If it is necessary to reproduce the received data, the flow advances to Step SD6 whereat an event process is per- 
formed. The event process is performed for MIDI data and image data, the details thereof being later described with 
reference to the flow chart of Fig. 8. 

At Step SD7, the sequence number is counted up. At Step SD8, it is checked whether there is data buffered in the 
buffer at Step SD10, the data having the correct sequence number 45, and whether the current time at the home com- 
puter 9 being the same as or later than the reproduction time 46. 

If there is no data to be reproduced, the reception process is terminated, whereas if there is data to be reproduced, 
the flow returns to Step SD6 to perform the above processes at Steps SD6 and SD7. The received data whose order 
was changed by a communications error can be properly processed in the above manner. If the buffer has no data to 
be reproduced, the reception process is terminated. 

If data of a predetermined amount or more is stored in the buffer, it is judged that the data having the sequence 
number to be next processed was lost, the process for this data is skipped, and the process for the data having the next 
sequence number is performed. 

Fig. 8 is a flow chart illustrating the detailed operation of the event process at Sep SD6 of Fig. 7. 

At Step SE1 , the number of the data ID 44 (Fig. 4) is checked. If the number is "0 B . it means real event data and the 
flow advances to Step SE2 whereat the type of the event is checked. The type of an event includes a key-on event, a 
key-off event and a tone generator setting data event. 

If the type of the event is key-on, the flow advances to Step SE3 whereas the key-on event is registered in the key- 
on buffer 21a (Fig. 2) and transferred to the tone generator. Upon reception of the key-on event, the tone generator per- 
forms a process of starting sound reproduction. Thereafter, the process returns to Step SD7 shown in Fig. 7. 

If the type of the event is key-off, the flow advances to Step SE4 whereat the key-on buffer 21 is searched. If there 
is the same key code (sound pitch), the key-On event in the key-on buffer 21 a is deleted, and the key-off event is trans- 
ferred to the tone generator. Upon reception of the key-off event, the tone generator performs a process of stopping 
sound reproduction. Thereafter, the process returns to Step SD7 shown in Fig. 7. 

If the type of the event is tone generator setting data, the flow advances to Step SE5 whereat the tone generator 
setting data is registered in the tone generator setting buffer 21b (Fig. 2) and transferred to the tone generator. Upon 
reception of the tone generator setting data, the tone generator sets a tone color, a sound volume and the like. There- 
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after, the process returns to Step SD7 shown in Fig. 7. 

If the number of the data ID is "1", it means the received data is recovery key data, and the flow advances to Step 
SE6 whereat the recovery key data is compared with the corresponding key-on event in the key-on buffer 21a and dif- 
ferent points between them are used as a new key-on event which is registered in the key-on buffer 21a and transferred 
to the tone generator. In this manner, a key-on event lost by a communications error can be recovered. 

At Step SE7. a reception of the recovery key data is registered. This registration allows to confirm the key-on state 
until the recovery key data is not periodically transmitted after the key-off. If the recovery key data is not periodically 
transmitted even if a key-on event is present in the key-on buffer, it means that the key-off event was lost. Thereafter 
the process returns to Step SD7 shown in Fig. 7. 

If the number of the data ID is n 2", it means that the received data is tone generator setting data, and the flow 
advances to Step SE8 whereat the recovery tone generator setting data is compared with the corresponding tone gen- 
erator setting data in the tone generator setting buffer 21b and different points between them are used as a new tone 
generator setting data event which is registered in the tone generator setting buffer 21b and transferred to the tone gen- 
erator. In this manner, a tone generator setting data lost by a communications error can be recovered. Thereafter, the 
process returns to Step SD7 shown in Fig. 7. 

If the number of the data ID is °Z n , it means that the received data is image data, and the flow advances to Step 
SE9 whereat a process of displaying the image data on the display device is performed. The image data is processed 
with a lower priority than the MIDI data. Basically, a display image is processed in the unit of one frame. In order to give 
the MIDI data a priority over the image data, the display image may be a still image. Thereafter, the process returns to 
Step SD7 shown in Fig. 7. If the number of the data ID is "4", it means that the received data is sound data, and the flow 
advances to Step SE10 whereat a process of reproducing the sound data is performed. 

Fig. 9 is a flow chart illustrating the operation of an interrupt process to be executed by the home computer 9. This 
interrupt process is performed at a predetermined interval in response to the timing supplied from the timer 24. For 
example, the interrupt process is performed at an interval of 100 to 200 \xs. 

At Step SF1. the key-on buffer 21a (Fig. 2) is searched. At Step SF2, of key-on events stored in the key-on buffer 
21a (Fig. 2), the key-on event to which recovery key data is not transmitted for a predetermined period is deleted, and 
a key-off event is transferred to the tone generator. After the key-off event is transferred, the process returns to the proc- 
ess which was executed before this interrupt process. The predetermined period may be a time duration sufficient for 
receiving the recovery key data at least twice. 

With the above recovery process, a false continuation of sound reproduction can be avoided even if a key-off event 
is lost by a communications error. The judgement that recovery key data is not received for the predetermined period 
becomes possible because the reception of recovery data is registered at Step SE7 in Fig. 8. 

Since the recovery key data and recovery tone generator setting data (hereinafter, both the data are collectively 
called recovery data) are transmitted, a proper recovery is ensured even if there is data change or data loss. 

Next, a method of alleviating the traffic congestion of communications lines will be described. For the communica- 
tions of musical performance data and recovery data, a fairly large amount of data flows on a communications line of 
the network. The number of users accessing the server at the same time for attending the music concert is also very 
large. 

Under such circumstances, smooth reproduction of a musical performance by the home computer 9 of each user 
may become unable in some cases. In order to alleviate the congestion of communications lines, each of a plurality of 
proxity servers 12 shown in Fig. 1 reduces the data amount in accordance with the congestion degree of communica- 
tions lines. 

If the data amount is reduced, the sound quality or image quality is lowered. In this connection, each proxity server 
1 2 has a data reduction factor, data reduction method, and the number of accessible users, specific to the proxity server 

12. 

If the number of users accessing the proxity server 12 is small, the proxity server does not reduce the data amount, 
whereas if the number of accessing users becomes large, the proxity server reduces the data amount and transmits the 
reduced data. 

The following methods may be used for reducing the data amount 
(1) Data separation 

The proxity server receives the musical tone data (MIDI data), image data and sound information <audio data). The 
image data requires an image quality not so high as the MIDI data. Therefore, the proxity server may transmit only the 
MIDI data and sound information by separating the received data into MIDI data, sound information and image data. 
Similarly, each of the MIDI data, sound information and image data may be separated further to transmit only necessary 
data. The congested traffic of communications lines can be alleviated by transmitting only important data. 
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(2) Data discrimination 

The proxity server may determine the priority order of data and preferentially transmit important data. Specifically, 
while communications lines are congested, only important data is transmitted during this period, and during a later 
period the data not important is transmitted. Although this method does not reduce the total data amount, the data 
amount transmitted during each period can be reduced. 

For example, loss of a key-off event is a fetal error as compared to a loss of a key-on event. Therefore, the key-off 
event has a higher importance degree of data. The proxity server may separate the received packet into a key-off event 
and other data to first transmit the key-off event and then transmit the other data. 

If a packet contains both a key-on event and a key-off event and the key-off event separated from the packet is first 
transmitted and then the key-on packet is transmitted, this transmission order is not proper. In this case, therefore, both 
the events are preferably not transmitted. Similarly, if there is any discrepancy in preferential transmission, a necessary 
countermeasure is required. 

(3) Data resolution setting 

In order to reduce the data amount, the proxity server may transmit data at a low resolution to a user. For example, 
if the sound volume increases by one step as the time lapses, the data at a low resolution increasing the sound volume 
by two steps is transmitted to halve the data amount. The resolution may be lowered not only for the sound volume but 
also for other control data (data supplied from controllers) such as a pitch event and an after-touch event. Different res- 
olutions may be set in accordance with the type of controller to lower the total resolution of a plurality of control data 
sets. 

(4) Time resolution setting 

The recovery data is periodically transmitted. Therefore, the proxity server may prolong the period of transmitting 
recovery data in order to reduce the data amount The transmission rate of image data may be lowered. For example, 
eight frames per second may be lowered to four frames per second to reduce the data amount. 

Next, the proxity server will be described. The structure of the proxity server is similar to that of the computer shown 
in Fig. 2. The tone generator 28 and MIDI interlace 30 are not necessarily required. 

Fig. 10 shows the structure of a RAM of the proxity server 12 shown in Fig. 1 . 

RAM of each of a plurality of proxity servers 12a, 12b, 12c.... stores the following data. 

(1) The number of current accesses: 51 

The number 51 of current accesses is the number of users (communication lines) now accessing the proxity server 
and changes with time. The access number is initially set to "0", increases as the number of accessing users increases, 
and decreases as the number of accessing users decreases. 

(2) Overflow flag: 52 

The overflow flag 51 indicates whether the proxity server is in an overflow state. The overflow flag 52 is initially set 
to "0" which means no overflow. When the number of users accessing the proxity server reaches an allowable access 
number 54 to be later described, the overflow flag 52 is set to "1 

(3) Current thinning index: 53 

The current thinning index 53 is a currently set thinning index This index indicates a data reduction (also called 
data thinning hereinafter) factor and a thinning method. The thinning index 53 is initially set to which means no data 
thinning. Table 1 shows examples of the thinning indices. 



Table 1 



Thinning index 


Thinning method 


0 
1 


All data is transmitted (no thinning) 

Every third recovery tone generator setting data is transmitted 
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Table 1 (continued) 





Thinning index 


Thinning method 


5 


2 


Every fourth recovery tone generator setting data is transmitted 


10 


m 


Everv third recover v kev data is transmitted 


15 


n 

n+1 


Resolution of control data is set to 1/2 
Resolution of control data is set to 1/4 


20 








z 


Image data is not transmitted 



25 A combination of any ones of the thinning indices may be used as one thinning index. 



(4) Allowable access number: 54 

The allowable access number 54 is the maximum number of users (communication lines) accessible to the proxity 
30 server and may take any desired value. The allowable access number corresponds to the maximum access capacity of 
the proxity server. 

(5) Allowable thinning index: 55 

35 The allowable thinning index 55 is the maximum allowable value of a thinning index allowed by the proxity server. 
Preferably the allowable thinning index is the allowable maximum value of total thinning by each weighted thinning 
method. For example, the thinning index corresponds to a thinning ratio, and the larger the index, the larger the thinning 
ratio. Each proxity server can determine its specific allowable thinning index in accordance with the access number. 

40 (6) Table number: 56 

The table number 56 is the number of a table which shows a correspondence between the access number and the 
thinning index. Fig. 1 1 shows examples of characteristic curves 60a, 60b and 60c of three tables. Each table shows a 
correspondence between the access number and the thinning index. It is preferable that the larger the access number, 
45 the larger the access index and the larger the data reduction amount. The characteristic curves 60a to 60c are not nec- 
essary to take a continuous value, but may take a discrete value. The value of the thinning index does not always indi- 
cate the data reduction amount, so that it is not necessarily required to take a larger value as the access number 
increases. These tables are stored in a memory (e.g., RAM). 

A plurality of tables (e.g., three tables 60a to 60c) are prepared, and the number of the table most suitable for the 
so proxity server is used as the table number 56. 

(7) Next candidate proxity server address: 57 

The next candidate proxity server address 57 is an address of the next candidate proxity server of the proxity server 
55 in concern when the latter overflows. When a user accesses a proxity server and this server is overflowing, this access 
is automatically switched to the proxity server indicated by the next candidate proxity server address. 
Fig. 12 is a flow chart illustrating the operation of the proxity server when a user accesses it. 
At Step SG1 , when an access from a user (client) is detected, the processes at Step SG2 and following Steps are 
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performed. By accessing the proxity server, a user can obtain MIDI data, sound Information and image data. 

At Step SG2, it is checked whether the overflow flag 52 (Rg. 10) is "0" or "1". If the overflow flag is T, it means that 
the access number is larger than the allowable access number, and the flow advances to Step SG6. 

At Step SG6 t the access is switched to the next candidate proxity server indicated by the next candidate proxity 
server address 57 (Fig. 10). Namely, the user access is automatically switched to the next proxity server. As a result, 
the user accesses this next proxity server. If the next candidate proxity server is also overflowing, the second next prox- 
ity server is accessed. In this manner, if the accessed proxity server is congested, the access is automatically switched 
to the proxity server not congested. After the access is switched to another proxity server, the first accessed proxity 
server terminates its operation. 

If it is judged at Step SG2 that the overflow flag is "CT, it means that the access number of this proxity server is 
smaller than the allowable access number, and the ftow advances to Step SG3. 

At Step SG3, the current access number 51 (Fig. 10) is incremented by 1. The access number 51 is the number of 
users currently accessing the proxity server. Each time an access from a user is permitted, the proxity server incre- 
ments the access number 51 by 1. 

Next, with reference to the table (Rg. 11) indicated by the table number 56 (Rg. 10), the thinning index correspond- 
ing to the current access number 51 is obtained and written in the memory as the current thinning index 53. If the 
obtained thinning index is the same as the previously used one. the write operation may be omitted. As the access 
number becomes large, the thinning index having a large thinning ratio is selected. 

At Step SG4, it is checked whether the current access number 51 is same as the allowable access number 54 (Rg. 
10). If same, the flow advances to Step SG5 whereat the overflow flag 52 is set to "1 " so as not to increase the access 
number more than the allowable access number. If not same, the overflow flag is maintained w 0\ Thereafter, the above 
operation by the proxity server is terminated. 

Rg. 13 is a flow chart illustrating the operation of the proxity server when a user releases its access. 

At Step SH1, when an access release by a user (client) is detected, the processes at Step SH2 and following Steps 
are performed. 

At Step SH2, the current access number 51 (Rg. 1 0) is decremented by 1 . Each time an access release by a user 
is detected, the proxity server decrements the access number 51 by 1 . 

Next, with reference to the table (Rg. 11) indicated by the table number 56 (Rg. 10), the thinning index correspond- 
ing to the current access number 51 is obtained and written in the memory as the current thinning index 53. If the 
obtained thinning index is the 6ame as the previously used one, the write operation may be omitted. As the access 
number becomes small, the thinning index having a small thinning ratio is selected. 

At Step SH3. it is checked whether the overflow flag 52 (Rg. 10) is "1". If the overflow flag is "1 the flow advances 
to Step SH4 to set the overflow flag to "0* so as to permit a new access. If the overflow flag is M 0 n , it is maintained M 0 W . 
Thereafter, the above operation by the proxity server is terminated. 

The overflow flag may not be checked at Step SH3, and the overflow flag is set to "1 w irrespective of the overflow 
value of "1" or "0". Also in this case, the operation equivalent to the above can be realized. 

Rg. 14 is a flow chart illustrating the operation of the proxity server when it receives data from the main server. 

At Step SI1, the proxity server receives data in the packet form from the main server 7 (Fig. 1). The data includes 
musical tone data (inclusive of recovery data), sound information and image data. The proxity server receives data not 
thinned. A plurality of proxity servers all receive the same data. 

At Step SI2, in accordance with the current thinning index 53 (Rg. 10), a thinning method (state) is determined. For 
example, if the thinning index is "0 n , the data is not thinned. 

At Step SI3. in accordance with the determined thinning method, the predetermined data is deleted from the data 
field 42 (Rg. 4) of the received packet. 

At Step SI4, the checksums 43, data length 47 and the like in the packet header field 41 (Fig. 4) are renewed to 
match the data whose predetermined data was deleted. 

At Step SIS. the renewed packet is transmitted to the WWW server 8 (Rg. 1). The WWW server 8 receives the pre- 
determined thinned data. All the proxity servers receiving the same data from the main server 7 may perform different 
thinning operations to transfer data to the WWW server. The above processes by the proxity server are thereafter ter- 
minated. 

Rg. 1 5 is a flow chart illustrating the operation of the proxity server when it thins the recovery data. When recovery 
data is received, a recoverjime register is reset to "0", and thereafter it is incremented by 1 each time a predetermined 
time lapses. The recover_timer register shows a lapse time after the previous recovery data is received. 

At Step SJ1, it is checked whether the packet received from the main server 7 is recovery data. This check is per- 
formed by referring to the data ID 44 (Rg. 4). If the value of the data ID is "1" or "2", the received packet is recovery 
data. This flow chart illustrates the operation of thinning recovery data, and if data other than the recovery data is 
received, this process is terminated immediately. When the recovery data is received, the flow advances to Step SJ2. 

At Step SJ2, it is checked whether the value of the recoverjimer register is larger than the time designated by the 
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thinning index. The recoverjimer register shows a lapse time after the previous recovery data is received. The time 
designated by the thinning index corresponds to the period of transmitting the recovery data. 

If the value of the recoverjimer register is larger than the time designated by the thinning index, the flow advances 
to Step SJ3. 

At Step SJ3, the received packet is transferred to the WWW server 8. At Step SJ4, the recoverjimer register is set 
to n 0 n to terminate the above processes. The recoverjimer register is counted up at a predetermined time interval by 
an interrupt process. This interrupt process is enabled at the predetermined time interval by the timer 24 shown in Fig. 
2. 

If it is judged at Step SJ2 that the value of the recoverjimer is not larger than the time designated by the thinning 
index, it means that the predetermined time does not still lapse, and the flow advances to Step SJ5. 

At Step SJ5, all the data field of the received packet is discarded and only the header field is left. At Step SJ6, the 
packet constituted of only the header field is transferred to the WWW server 8 to thereafter terminate the above proc- 
esses. 

In the above operation, the packet with only the header field is transferred. Instead, the packet itself may not be 
transferred in order to further reduce the data amount. In this case, however, it is necessary to judge whether the packet 
is deleted by thinning or it is lost by a communications error. If the packet is lost by a communications error, it is neces- 
sary to recover it, whereas if it is deleted by thinning, it is unnecessary to recover it. 

Instead of counting up the value of the recover Jimer register by the interrupt process, the number of receptions of 
recovery data from the main server may be counted. For example, of three receptions of recovery data from the main 
server, the recovery data received at the first and second times is deleted and the packets with only the header field are 
transferred, and for the recovery data received at the third time, the packet with both the header and data fields is trans- 
ferred. Wrth this process, it is not necessary to count up the value of the recoverjimer register by the interrupt process. 

In order to simplify the process, the sequence number 45 and time data 46 in the packet may not be renewed. Con- 
versely, if the data quality is to be improved, the sequence number 45 and time data 46 may be renewed. This additional 
data renewal can recover more reliably the data lost by communication errors such as data loss and data change. 

Fig. 16 is a flow chart illustrating the operation of the proxity server when it transmits a key-off event with a priority 
over the key-on event. 

At Step SK1 , the key-off event data is derived from the packet received from the main server, and the flow advances 
to Step SK2. If the packet does not contain key-off event data, the whole received packet is transferred to the WWW 
server 8. 

At Step SK2, a new packet having the data field containing only the derived key-off event data is generated. 
At Step SK3, the newly generated packet is transferred to the WWW server 8. 

At Step SK4, the remaining packet with the keynrff event data being deleted is transferred to the WWW server 8 to 
thereafter terminate the above processes. In the above processes, the data in the packet is separated into the key-off 
event data and other data, first at Step SK3 the key-off event data is preferentially transferred, and then at Step SK4 the 
other data is transferred. 

As the transfer timing at Step SK4 is delayed from the transfer timing at Step SK3, data can be transferred in a dis- 
persed manner, the traffic congestion can be alleviated as compared to the case where all the data is transferred at the 
same time. 

Fig. 17 is a flow chart illustrating the operation of the proxity server when it transfers data by deleting the image 
data. 

At Step SL1 , it is checked whether the packet received from the main server is image data. This check is realized 
by referring to the data ID 44 (Fig. 4). If the value of the data ID is -3", the received packet is image data. This flow chart 
illustrates the operation of deleting image data, and if data other than the image data is received, this process is termi- 
nated immediately. When the image data is received, the flow advances to Step SL2. 

At Step SL2, the data field of the received packet is deleted and only the header field is left. At Step SL3, a packet 
with only the header field is transferred to the WWW server 8 to thereafter terminate the above processes. 

Also in this case, instead of transferring the packet with only the header field, the packet itself may not be trans- 
ferred in order to further reduce the data amount 

Fig. 18 is a flow chart illustrating the operation of the proxity server when it transfers data by lowering the resolution. 

At Step SM1 , data to be thinned is derived from the packet received from the main server, and the flow advances 
to Step SM2. The data to be thinned includes control data such as volume data, pitch event data and after-touch event 
data. If the packet does not contain data to be thinned, the whole received packet is transferred to the WWW server 8. 

At Step SM2, the data is converted into values corresponding to a designated resolution. For example, if a resolu- 
tion is 1/4, the data sets of the same type in the packet are all multiplied by 1/4 and the decimal fractions are cut off. 

At Step SM3, of the data sets having the same converted value, only one data set is left in the packet and ail other 
data sets are deleted. The resultant packet is transferred to the WWW server. 

The data to be thinned may be subjected to modulo calculation, and only the data sets with the calculation result 
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of "0" may be left to delete all other data sets. 

A plurality type of data sets to be thinned may be provided with each type being assigned a different resolution. 

In the embodiment described above, musical performance information (MIDI data), sound data (audio data) and 
musical performance image (image data) in a concert hall can be supplied to a number of users by using the Internet. 
A user can obtain MIDI data and image data in real time at home without going to the remote concert hall. 

If the encoder at each of a plurality of concert halls adds time data to M I Dl data and the like, a simultaneous session 
by a plurality of concert halls becomes possible. 

Each of a plurality of proxity servers reduces the data amount in accordance with the number of accesses to the 
proxity server, so that the traffic congestion can be alleviated. If the number of proxity servers is increased, the traffic 
congestion can be alleviated without thinning the data. If the data is thinned, the traffic congestion can be alleviated 
even if the number of proxity servers is small. 

If the data amount is reduced, the sound quality and image quality are degraded. In this connection, each proxity 
server can select a data thinning ratio and method most suitable for the proxity server, and can set the desired number 
of accessible users. 

The proxity server transmits information on the data thinning ratio and method to a user so that this information can 
be displayed on the screen of the display device of a home computer. For example, "Now. with lowered sound quality", 
"Now, with only musical tone data" or the like can be displayed. This display is preferably made when a user accesses 
the proxity server. A user can access a desired proxity server by referring to this display. 

A mirror server is also used in the Internet. However, this mirror server is different from the proxity server of the 
embodiment in that all mirror servers perform the same operation and supply the same data. 

The embodiment is not limited only to the Internet, but other communication systems may also be used, for exam- 
ple, digital serial communications of IEEE1394 specifications, communication satellites and the like. 

The present invention has been described in connection with the preferred embodiments. The invention is not lim- 
ited only to the above embodiments. It is apparent that various modifications, improvements, combinations, and the like 
can be made by those skilled in the art. 

Claims 

1 . A musical tone data communications system, comprising: 

input means for inputting music data including MIDI data; 
packet means for packeting the music data; and 

transmitting means for transmitting the packeted music data over a communication network. 

2. A musical tone data communication system according to claim 1 , further comprising: 

music data generating means for generating the music data representing a musical performance by a player. 

3. A musical tone data communication system according to daim 1 , further comprising: 

receiving means for receiving the packeted music data on the communication network transmitted by said 
transmitting means. 

4. A musical tone data communication system according to claim 3, further comprising: 

unpacket means for returning the packeted music data to the music data; and 

supply means for supplying the music data returned by said unpacket means to tone signal generator means. 

5. A musical tone data communication system, comprising: 

receiving means for receiving packeted music data including MIDI data on a communication network; 
unpacket means for returning the packeted music data received by receiving means to the music data; and 
supply means for supplying the music data returned by said unpacket means to tone signal generator means. 

6. A musical tone data communication system according to claim 5, wherein said tone signal generator means gen- 
erates a tone signal in accordance with the music data supplied from said supply means. 

7. A musical tone data communication system, comprising: 
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music data transmitting means for transmitting music data including MIDI data to a communication network; 
and 

recovery data transmitting means for transmitting recovery data to the communication network after said music 
data transmitting means has transmitted the music data, the recovery data indicating that an instruction repre- 
s sented by the music data has not yet been finished. 

8. A musical tone data communication system according to claim 7, wherein said recovery data transmitting means 
periodically transmits the recovery data. 

w 9. A musical tone data communication system according to claim 7, wherein said music data transmitting means 
transmits a key-on event data corresponding to a start of production of a tone corresponding to said music data at 
a first timing and a key-off event data corresponding to a termination of production of said tone at a second timing, 
and said recovery data transmitting means transmits the recovery data during a period after the first timing and 
before the second timing. 

15 

10. A music data communication system according to daim 7, further comprising: 

receiving means for receiving the music data transmitted by said music data transmitting means and the recov- 
ery data transmitted by said recovery data transmitting means; and 
20 supply means for supplying a tone parameter corresponding to the MIDI data to tone signal generator means 

when the receiving means receives the music data, and for supplying a tone parameter corresponding to the 
recovery data to said tone signal generator means when the receiving means receives the recovery data. 

1 1 . A data communications system comprising: 

25 

receiving means for receiving data, said receiving means including a plurality of receivers; 
transmitting means; and 

access checking means for checking the number of said receivers which access said transmitting mean, 
said transmitting means reducing the amount of data received by said receiving means in accordance with the 
30 access number and transmitting the reduced data to said receiving means. 

12. A data communications system according to claim 11, wherein said transmitting means can reduce the amount of 
data through an operation of data separation, data discrimination, data resolution setting, time resolution setting, 
or a combination thereof. 

35 

13. A communication system having a plurality of communications apparatuses, each having receiving means and 
transmitting means, wherein: 

said receiving means of the plurality of communications apparatuses receive the same data including MIDI 
40 data; 

said transmitting means of the plurality of communications apparatuses can reduce the amount of data 
received by said receiving means and can transmit the reduced data; and 

the data reduction by transmitting means of one of the plurality of communications apparatuses is done differ- 
ently from that by transmitting means of the plurality of communications apparatuses. 

45 

14. A communication system according to claim 13, further comprising: 

access checking means provided at each of the plurality of communications apparatuses for -checking the 
number of receivers of receiving means which access transmitting means of the plurality of communication 
so apparatus, wherein said transmitting means apparatuses reduces the amount of data received by said receiv- 

ing means in accordance with the access number and transmitting the reduced data to said receiving means. 

15. A communications system according to claim 13, wherein said transmitting means of each of the plurality of com- 
munications apparatuses can also transmit information on data reduction. 

55 

16. A communications system according to claim 13, wherein a receiver at each of the plurality of communications 
apparatuses can make a new access to transmitting means of said one of the plurality of communication appara- 
tuses according to the number of receivers which are accessing said transmitting means. 
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17. A music date communications system according to claim 1, wherein the music data further includes sound data 
representing a sound. 

18. A music data communications system according to claim 17, wherein said sound data includes voice data repre- 
senting a voice. ^ 

19. A music data communications system according to claim 1, wherein the music data further includes image data 
representing an image. 

20. A music data communications system according to claim 19, wherein said image data represents at least one of a 
moving picture, a still picture or a combination thereof. 

21. A music data communications system according to daim 1, wherein said transmitting means transmits the pack- 
eted music data essentially in real time. 

22. A music data communications system according to claim 1 , wherein said transmitting means transmits the pack- 
eted music data in parallel to a plurality of receivers. 

23. A music data communications system according to claim 22, said receiver is a home computer. 

24. A music data communications system according to claim 5, wherein the music data further includes sound data 
representing a sound. 

25. A music data communications system according to claim 24, wherein said sound data includes voice data repre- 
senting a voice. 

26. A music data communications system according to claim 5. wherein the music data further includes image data 
representing an image. 

27. A music data communications system according to claim 26. wherein said image data represents at least one of a 
moving picture, a still picture or a combination thereof. 

28. A music data communications system according to claim 5. wherein said output means outputs the music data 
essentially in real time. 

29. A music data communications system according to claim 7, wherein the music data further includes sound data 
representing a sound. 

30. A music data communications system according to claim 29, wherein said music data includes voice data repre- 
senting a voice. 

31. A music data communications system according to claim 7, wherein the music data further includes image data 
representing an image. 

32. A music data communications system according to claim 31 , wherein said image data represents at least one of a 
moving picture, a still picture or a combination thereof. 

33. A data communications system according to claim 11, wherein the data further includes sound data representing 
a sound. 

34. A data communications system according to claim 33, wherein said sound data includes voice data representing a 
voice. 

35. A data communications system according to claim 7, wherein the data further includes image data representing an 
image. 

36. A data communications system according to claim 35, wherein said image data represents at least one of a moving 
picture, a still picture or a combination thereof. 
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37. A data communications system according to claim 7, wherein said data include at least two among MIDI data, 
image data, sound data and recovery data, and said transmitting means reduces data amount of at least one of 
said at least two. 

38. A communication system according to claim 13, wherein said same data include at least two among MIDI data, 
image data, sound data and recovery data, and 

said transmitting means reduces data amount of at least one of said at least two, the kind of data reduced by 
transmitting means of one of the plurality of communications apparatuses being different from that reduced by 
transmitting means of another of the plurality of communications apparatuses. 

39. A communication system according to claim 15, wherein said information represents what data is reduced. 

40. A communication system according to claim 15, wherein said information represents a fact that data have been 
reduced. 

41 . A communication system according to claim 1 3, wherein a receiver at each of the plurality of communications appa- 
ratuses can make a new access to transmitting means of another of the plurality of communications apparatuses 
according to the number of receivers which are accessing transmitting means of said one of the plurality of com- 
munications apparatuses. 

42. A musical tone data communications system, comprising: 

inputer for inputting music data including MIDI data; 
packeter for packeting the music data; and 

transmitter for transmitting the packeted music data over a communication network. 

43. A musical tone data communication system, comprising: 

receiver for receiving packeted music data including MIDI data on a communication network; 
unpacketer for returning the packeted music data received by receiver to the music data; and 
supplier for supplying the music data returned by 6aid unpacketer to tone generator. 

44. A musical tone data communication system, comprising: 

music data transmitter for transmitting music data including MIDI data to a communication network; and 
recovery data transmitter for transmitting recovery data to the communication network after said music data 
transmitter has transmitted the music data, the recovery data indicating that an instruction represented by the 
music data has not yet been finished. 

45. A data communications system comprising: 

a plurality of receivers for receiving data, 
transmitter; and 

access checker for checking the number of said receivers which access said transmitter, 

said transmitter reducing the amount of data received by said receivers in accordance with the access number 

and transmitting the reduced data to said receivers. 

46. A communication system having a plurality of communications apparatuses, each having receiver and transmitter, 
wherein: 

said receiver of the plurality of communications apparatuses receive the same data including MIDI data; 
said transmitter of the plurality of communications apparatuses can reduce the amount of data received by said 
receiver and can transmit the reduced data; and 

the data reduction by transmitter of one of the plurality of communications apparatuses is done differently from 
that by transmitter of the plurality of communications apparatuses. 

47. A musical tone data communications method comprising the steps of: 
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(a) inputting music data including MIDI data; 

(b) packeting the music data; and 

(c) transmitting the packeted music data over a communication network. 

48. A musical tone data communication method comprising the steps of: 

(a) receiving packeted music data including MIDI data on a communication network; 

(b) unpacketing and returning the packeted music data to the music data; and 

(c) supplying the returned music data to tone generator. 

49. A musical tone data communication method comprising the steps of: 

(a) transmitting music data including MIDI data to a communication network; and 

(b) transmitting recovery data to the communication network after the music data is transmitted, the recovery 
data indicating that an instruction represented by the music data has not yet been finished. 

50. A data communications method comprising the steps of: 

(a) receiving data; 

(b) checking the number of communications lines accessed externally; and 

(c) reducing the amount of received data in accordance with the access number, and transmitting the reduced 
data to the communications lines accessed externally. 

51. A data communication method comprising the steps of : 

(a) receiving the same data including MIDI data at a plurality of communications apparatuses; and 

(b) reducing different data in the same data received at one and another of the plurality of communications 
apparatuses and transmitting the resultant data. 

52. A data communication method comprising the steps of: 

(a) receiving the same data including MIDI data at a plurality of communications apparatuses; 

(b) checking the number of communications lines accessed externally at each of the plurality of communica- 
tions apparatuses; and 

(c) reducing the amount of data to be received at each of the plurality of communications lines in accordance 
with the access number, and transmitting the reduced data to the communications lines accessed externally, 
wherein different data in the same data received at one and another of the plurality of communications appa- 
ratuses is reduced and the resultant data is transmitted. 

53.. A medium storing a computer executable program, the program comprising the steps of: 

(a) inputting music data including MIDI data; 

(b) packeting the music data; and 

(c) transmitting the packeted music data over a communication network. 

54. A medium storing a computer executable program, the program comprising the steps of: 

(a) receiving packeted music data including MIDI data on a communication network; 

(b) unpacketing and returning the packeted music data to the music data; and 

(c) supplying the returned music data to tone generator. 

55. A medium storing a computer executable program, the program comprising the steps of: 

(a) transmitting music data including MIDI data to a communication network; and 

(b) transmitting recovery data to the communication network after the music data is transmitted, the recovery 
data indicating that an instruction represented by the music data has not yet been finished. 

56. A medium storing a computer executable program, the program comprising the steps of: 
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(a) receiving data; 

(b) checking the number of communications lines accessed externally; and 

(c) reducing the amount of received data in accordance with the access number, and transmitting the reduced 
data to the communications lines accessed externally. 

57. A medium storing a computer executable program, the program comprising the steps of: 

(a) receiving the 6ame data including MIDI data at a plurality of communications apparatuses; and 

(b) reducing different data in the same data received at one and another of the plurality of communications 
apparatuses and transmitting the resultant data. 

58. A medium storing a computer executable program, the program comprising the steps of: 

(a) receiving the same data including MIDI data at a plurality of communications apparatuses; 

(b) checking the number of communications lines accessed externally at each of the plurality of communica- 
tions apparatuses; and 

(c) reducing the amount of data to be received at each of the plurality of communications lines in accordance 
with the access number, and transmitting the reduced data to the communications lines accessed externally, 
wherein different data in the same data received at one and another of the plurality of communications appa- 
ratuses is reduced and the resultant data is transmitted. 
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